1. Field of the Invention
The present invention relates to a method for updating secret shared data in a wireless communication system.
2. Description of Related Art
The U.S. currently utilizes three major wireless systems, with differing standards. The first system is a time division multiple access system (TDMA) and is governed by IS-136, the second system is a code division multiple access (CDMA) system governed by IS-95, and the third is the Advanced Mobile Phone System (AMPS). All three communication systems use the IS-41 standard for intersystem messaging, which defines the authentication procedure when updating the secret shared data.
FIG. 1 illustrates a wireless system including an authentication center (AC) and a home location register (HLR) 10, a visiting location register (VLR) 15, and a mobile 20. While more than one HLR may be associated with an AC, currently a one-to-one correspondence exists. Consequently, FIG. 1 illustrates the HLR and AC as a single entity, even though they are separate. Furthermore, for simplicity, the remainder of the specification will refer to the HLR and AC jointly as the AC/HLR. Also, the VLR sends information to one of a plurality of mobile switching centers (MSCs) associated therewith, and each MSC sends the information to one of a plurality of base stations (BSs) for transmission to the mobile. For simplicity, the VLR, MSCs and BSs will be referred to and illustrated as a VLR. Collectively, the ACs, HLRs, VLRs, MSCs, and BSs operated by a network provider are referred to as a network.
A root key, known as the A-key, is stored only in the AC/HLR 10 and the mobile 20. There is a secondary key, known as Shared Secret Data SSD, which is sent to the VLR 15 as the mobile roams (i.e., when the mobile is outside its home coverage area) . SSD is generated from the A-key and a random seed RANDSSD using a cryptographic algorithm or function. A cryptographic function is a function which generates an output having a predetermined number of bits based on a range of possible inputs. A keyed cryptographic function (KCF) is a type of cryptographic function that operates based on a key; for instance, a cryptographic function which operates on two or more arguments (i.e., inputs) wherein one of the arguments is the key. From the output and knowledge of the KCF in use, the inputs can not be determined unless the key is known. Encryption/decryption algorithms are types of cryptographic functions. So are one-way functions like pseudo random functions (PRFs) and message authentication codes (MACs). The expression KCF.sub.SK (R.sub.N ') represents the KCF of the random number R.sub.N ' using the session key SK as the key. A session key is a key that lasts for a session, and a session is a period of time such as the length of a call.
In the IS-41 protocol, the cryptographic function used is CAVE (Cellular Authentication and Voice Encryption). When the mobile 20 roams, the VLR 15 in that area sends an authentication request to the AC/HLR 10, which responds by sending that mobile's SSD. Once the VLR 15 has the SSD, it can authenticate the mobile 20 independently of the AC/HLR 10. For security reasons, the SSD is periodically updated.
FIG. 2 illustrates the communication between the AC/HLR 10, the VLR 15 and the mobile 20 to update the SSD.
As discussed above, the AC/HLR 10 generates a random number seed RANDSSD, and using the CAVE algorithm generates a new SSD using the random number seed RANDSSD. The SSD is 128 bits long. The first 64 bits serve as a first SSD, referred to as SSDA, and the second 64 bits serve as a second SSD, referred to as SSDB. As shown in FIG. 2, the AC/HLR 10 provides the VLR 15 with the new SSD and the RANDSSD. The VLR 15 then sends the RANDSSD to the mobile 20 along with a session request SR. The session request SR instructs the mobile 20 to perform the SSD update protocol which is described in detail below. In response to receipt of the RANDSSD and the session request SR, the mobile 20 uses the CAVE algorithm to generate the new SSD using the RANDSSD, and generates a random number R.sub.M using a random number generator. The mobile 20 sends the random number R.sub.M to the VLR 15. The mobile 20 also performs the CAVE algorithm on the random number R.sub.M using the new SSDA as the key. This calculation is represented by CAVE.sub.SSDA (R.sub.M).
One of the VLR 15 and the AC/HLR 10, also calculates CAVE.sub.SSDA (R.sub.M), and sends the result to the mobile 20. The mobile 20 authenticates the network if CAVE.sub.SSDA (R.sub.M), which it calculated, matches that received from the network.
Next, and usually after receiving a signal from the mobile 20 indicating verification, the VLR 15 generates a random number R.sub.N, and sends the random number R.sub.N to the mobile 20. Meanwhile, the VLR calculates CAVE.sub.SSDA (R.sub.N). Upon receipt of R.sub.N, the mobile 20 calculates CAVE.sub.SSDA (R.sub.N), and sends the result to the VLR 15. The VLR 15 authenticates the mobile if CAVE.sub.SSDA (R.sub.N) which it calculated, matches that received from the mobile 20. The random numbers R.sub.M and R.sub.N are referred to as challenges, while CAVE.sub.SSDA (R.sub.M) and CAVE.sub.SSDA (R.sub.N) are referred to as challenge responses. Once the authentication is complete, the mobile 20 and the network generate session keys using SSDB.
In this protocol, the SSD is itself used to answer the challenges from the mobile 20 and the network. This allows an attack when an old RANDSSD and SSD pair are revealed. Knowing this pair is enough to query the mobile 20, and answer its challenge. Thus an attacker can issue an SSD update to the mobile 20, and answer the challenge from the mobile. Once the revealed SSD is accepted, and despite a secure session key agreement protocol (i.e., a protocol on communication between a mobile and a network to establish a session key), the attacker can impersonate the network and place a call to the mobile 20 under fraudulent identities. For example, the impersonator can insert his own caller id or name and pretend to be someone else. The attacker can pretend to be a credit card company, and ask to verify card number and pin. Or even use the telephone company name in the caller name field and ask to verify calling card numbers, etc.